The present invention relates generally to data processing environments and, more particularly, to systems for accessing shared information and other resources, such as in a multi-user database system.
Computers are a powerful tool for the acquisition and processing of information. Computerized databases, which can be regarded as a kind of electronic filing cabinet or repository for collecting computerized data files, are particularly adept at processing vast amounts of information. As such, these systems serve to maintain information in database files or tables and make that information available on demand.
Between the actual physical database itself (i.e., the data actually stored on a storage device) and the users of the system, a database management system or DBMS is provided as a software cushion or layer. In essence, the DBMS shields the database user from knowing or even caring about underlying hardware-level details. Typically, all requests from users for access to the data are processed by the DBMS. For example, information may be added or removed from data files, information retrieved from or updated in such files, and so forth, all without knowledge of underlying system implementation. In this manner, the DBMS provides users with a conceptual view of the database that is removed from the hardware level. The general construction and operation of a database management system is known in the art. See e.g., Date, C., An Introduction to Database Systems, Volume I and II, Addison Wesley, 1990; the disclosure of which is hereby incorporated by reference.
Of particular interest to the present invention are those information processing systems which are operative in a shared fashion, i.e., by multiple users (or multiple processes) at a given time. A multi-user database implemented on a client/server platform is one such system. Typically, information sharing or connectivity between the users is provided by a computer network, which comprises several computers connected together as a group. At least one of the computers functions as a "server," providing network services to "clients" (other computers) connected to the network. In this manner, valuable information and resources, including programs, information tables, memory, disk space, printers, and the like, may be shared by several users.
In a multi-user environment, availability of current information to each user is an important consideration. To achieve this, these systems store data objects to be shared (e.g., records of a database file) at a single (logical) location, typically resident on the server. Each user receives access to this centrally-stored information by commanding processes which issue requests to the server for retrieving information of interest. Once received at the client computer, this information may be modified by the client's user and then posted back to the server.
Inherent in any multi-user computing system is a basic conflict between data integrity and concurrency, i.e., the need to let many users access the same data simultaneously. Specifically, the potential exists for one user to update a record thereby causing another user to now have an out-of-date version of that same record (i.e., a local copy of the record which does not reflect the update). Suppose, for example, that two users are both executing an application that reads a particular value from a database, performs a calculation on the value, and writes a new value back to the database. If this process begins concurrently, both users will read the same database value, e.g., three. Suppose the calculation is to increment the database value by one. After both users have finished, the new value stored in the database will be four. However, the correct value desired is five, since each of the two is intended to add one to the value of three. The concurrent actions of the two processes have interfered, thus leaving incorrect data in the database. Further safeguards are needed to avoid inconsistent versions of information records.
As one approach to ensuring data integrity, a system could allow only one user to use a particular data record at any given time. As this would be highly inconvenient to other users, it is an unacceptable approach. At the other extreme, the system could allow anyone on a network to use any record at any time. Such unrestricted access, however, would quickly lead to inconsistencies in the data, such as in the example above. Since the need for insuring data integrity must be balanced with the need to provide concurrent access, an important issue in designing any multi-user application therefore is deciding how to resolve simultaneous requests for the same data. And the need for concurrency control is perhaps most acute in a multi-user database system, where information is frequently or even constantly being updated by several users.
The most common mechanism employed for coordinating processes and controlling access to shared data objects is "locking." In its simplest form, locking an object, such as a database record, prevents other processes or transactions from accessing that object (or portion thereof) until the lock is released. This prevents one user or process from updating a data object which is currently being used by another.
An additional benefit is available to the holder of a lock. Since the lock guarantees that the information will not change (i.e., be modified by others), the lock holder may cache the accessed information in a local buffer, thereby avoiding repeated data access across notorously slow computer networks. In typical data access operation, for instance, numerous messages must be transmitted between a server and its often numerous clients. For example, messages are required for file operation (e.g., opening, reading, writing, closing, and the like) as well as lock management (e.g., set lock and release lock). With a lock in place for an object, however, the information of interest can be stored locally (cached) by the lock holder, since the lock guarantees that the object will not be changed by others.
Of course the touchstone of a multi-user environment is sharing. No one user or process can be given access to a given object for long periods of time to the exclusion of others. A lock must, therefore, be held for short periods of time, or at least be relinquished when others require access. The ability to cache data locally is therefore limited by the need of others to access the same information.
If this need to share a particular object is not great, however, then a lock may be applied to the object, and a copy of that object may be cached locally. Such an approach is described in METHOD AND SYSTEM FOR OPPORTUNISTIC LOCKING IN A NETWORKED COMPUTER SYSTEM, Intl. Application No. PCT/US90/04570, Intl. Publication No. WO 91/03024, Intl. Publication Date Mar. 7, 1991. Making the assumption that it is common for only a single user to be using a network at any one time, that system employs the notion of "opportunistic" locks. The first client to request access to an object is given opportunistic (qualified) exclusive access to that object; a copy of the object may be cached locally in the client. If another client also requests access, the first client relinquishes its exclusive access, with the corresponding opportunistic exclusive lock held by the first client also being lifted. Upon removal of its exclusive lock, however, the client can no longer rely on its cached copy of the information--others may now post changes to that very same information.
The foregoing approach has distinct limitations which limits its usefulness. First, the assumption that only a single user is using a network at any one time is becoming increasingly difficult to make. Early on in their history, networks were simply an adjunct to PCs, largely for printer sharing. Their capacity largely went unutilized. Today, however, networks form the backbone of corporate computing, as more and more companies are moving their data off mainframes and onto networks. Therefore, a more valid assumption would be that many users are using a network at any one time; the contention for a particular data object may in fact be quite high. In the above-described system, therefore, it is quite likely that opportunistic locks would have to be frequently relinquished, thus making the technique largely ineffective (or even counter-productive). Second, the approach requires the server to know the status of each client's context and to act accordingly. This interdependency of each client with the server (e.g., for receiving a command to relinquish an exclusive lock) is not desirable in today's heterogenous network environments.
Instead, what is needed are system and methods which allow clients to optimize disk access by maximizing use of local buffers, all without the need for the server to monitor the status of each client. Optimization of disk access should not decrease the autonomy which has made client/server systems such an attractive model for solving corporate information processing needs. The present invention fulfills this and other needs.